This chapter discusses the use of Kerberos authentication and export rule sets to provide security for data that is managed by the SpinServer system.
This section discusses the following security concepts:
Section 16.1.1 discusses Kerberos authentication.
Section 16.1.2 provides information about export rule sets.
Section 16.1.3 discusses the SpinAuth authentication mechanism.
Kerberos is a network authentication protocol developed at the Massachusetts Institute of Technology. Kerberos uses encryption keys to provide authentication for client/server applications. Authentication provides verification of a user's or process's identity to a server. In the SpinServer environment, Kerberos is used to provide authentication between virtual servers and NFS and CIFS clients.
Any entity (user or process) that can access Kerberos is given a Kerberos principal. A principal is a string that lists the following information:
Primary—The name of the user or process; for instance, igor.
Instance—A host name or other information that qualifies the primary; for instance, labServer.
Realm—A logical network served by a single Kerberos database and one or more Key Distribution Centers (KDCs). A KDC is a server that issues Kerberos tickets. Kerberos realms are listed in uppercase. An example realm name is EXAMPLE.COM.
A Kerberos principal combines the primary, instance, and realm in the form primary/instance@REALM; for instance, igor/labServer@EXAMPLE.COM.
For more information about Kerberos, see http://web.mit.edu/kerberos/www/.
Export rule sets enable you to restrict access to virtual file systems (VFSs) to clients that match specific IP addresses and minimum authentication strengths. Each VFS is associated with exactly one rule set. Each rule set is identified by a unique name and a unique numeric ID. A SpinCluster can contain up to 1,024 rule sets. Each cluster has at least one rule set with ID 0, which contains no rules. This rule set cannot be deleted, although it can be renamed or modified.
A newly installed or upgraded cluster contains only the default rule set. Each VFS on a new or upgraded cluster is associated with no rule set, and the default rule set is applied to it; however, if viewed with the filestorage vfs show-access command, the associated rule set is displayed as none. In a new cluster, the default rule set is associated with new VFSs, but you can also explicitly associate new VFSs with the rule set named none. The primary difference between allowing a new VFS to have the default rule set applied to it and applying the rule set named none to it is the inheritance or overriding of rule sets when the VFS is mounted or has its export rule set reset. See Section 13.2.3 and Section 13.2.10 for more information.
Rule sets consist of individual rules. A rule set can contain a large number of rules (approximately 4,000). Each rule specifies the number of mask bits in the client IP address that must be matched for that rule to apply to a particular client request. The rule also specifies the authentication levels that are required for both read-only and read-write operations. To have any access to a VFS, matching clients must authenticate at least as strongly as the authentication level specified by the read-only rule. To have write access to the VFS, matching clients must authenticate at least as strongly as the authentication level specified by the read-write rule. If a client makes an access request that is not permitted by the applicable rule set, the request fails with a permission-denied message. If a client IP address does not match any rule in the VFS's rule set, then access is denied, except in the special case in which the rule set is empty (contains zero rules). If a rule set is empty, then all accesses are implicitly permitted.
When using export rule sets, you can specify a netgroup name instead of an IP address and mask bits to match clients to an export rule. A netgroup is a named collection of arbitrary IP addresses that is stored in a NIS map.
Rules are evaluated in the order in which they appear in the rule set. You can reorder rules in a rule set.
You can modify a rule set dynamically on a running SpinServer system; however, changes can take up to two minutes to propagate and take effect.
Export rule sets are not specific to any one virtual server; however, because each virtual server has an independent NIS domain and the set of IP addresses that a netgroup matches is dependent on NIS, each netgroup-based rule can match different clients on different virtual servers that have different NIS domains.
SpinAuth is a lightweight authentication mechanism that improves the security of NFS requests, which are otherwise protected only by the AUTH_SYS mechanism. The AUTH_SYS mechanism, which is standard with NFS, does not provide secure authentication of client requests; NFS Kerberos provides strong authentication of client requests but has few available client programs. SpinAuth enables users to authenticate by using Kerberos and pass the authenticated identity to a SpinServer, which then caches the credentials for future requests from the users' clients.
The lifetime of the SpinAuth credential is the same as the lifetime of the Kerberos credential.
This section provides the following information:
Section 16.2.1 describes enabling the SpinServer system to use Kerberos authentication with the NFS protocol.
Section 16.2.2 describes enabling the SpinServer system to use Kerberos authentication with the CIFS protocol.
Section 16.2.6 describes setting up export rule sets for VFSs.
Section 16.2.7 describes setting up SpinAuth for authentication.
To enable the SpinServer system to use Kerberos authentication with the NFS protocol, perform the following steps:
Define a NIS domain in which Kerberos users are defined. See Section 15.2.1.1 for information.
Create a Kerberos realm configuration. See Section 16.2.3 for information.
Enable a virtual server to use Kerberos authentication by using the -kerbrealms parameter of the spinaccess nfs servers new or spinaccess nfs servers modify command. See Section 15.2.2 for more information.
Optionally, you can require NFS clients to use Kerberos authentication with a virtual server by specifying the -minauth parameter of the vservers servers new or vservers servers modify command. See Section 12.2.1 for more information.
Create mappings between Kerberos principal names and NIS names. See Section 16.2.4 for information.
Bind the virtual interface to a Kerberos-enabled virtual server by using the vservers servers bindif command. See Section 12.2.4 for more information.
Enable the SpinServer interface to use Kerberos. See Section 16.2.5 for information.
Note: If a Kerberos-related command fails, the failure is typically caused either by incorrect entry of case-sensitive data or by clock skew (if the clocks on the SpinServer and the KDC server are more than 300 seconds apart). If a Kerberos-related command fails, it is recommended that you check both of these possible factors. When checking for clock skew, ensure that the time-zone and date settings are correct on all machines. If the failure results from clock skew, it is recommended that you adjust the clocks on one or more servers.
Note: If you create a virtual server for a new Kerberos realm, you can see Kerberos clock-skew errors. These errors do not necessarily originate from the SpinServer; they can originate from a disagreement between the SpinServer and the Kerberos server (for a Microsoft Kerberos server, this is the domain controller or Active Directory server), which has its own clock-skew setting. To prevent this situation from occurring, synchronize the clocks of the SpinServer and the Kerberos server, and ensure that the SpinServer and domain controller use the same time-zone setting. For information on setting up Network Time Protocol (NTP) to keep clocks synchronized automatically, see Section 20.2.13 .
To enable the SpinServer system to use Kerberos authentication with the CIFS protocol, perform the following steps:
Define the Kerberos realm or realms that are to be used to control access to the SpinServer. See Section 16.2.3 for information.
Set up a CIFS domain for Kerberos authentication and account management. See Section 14.2.1 for information.
Create a CIFS-enabled virtual server in the target domain and realm. See Section 14.2.2.1 for information.
To create a Kerberos realm configuration, use the spinaccess kerberos realm new command. The command has the following syntax:
spinaccess kerberos realm new -configname configuration_name [-adaddr Active_Directory_address] [-clockskew clock_skew] -kdc KDC_address [-kdcport KDC_port] -kdcvendor {Microsoft | Other} [-adminaddr admin_server_address] [-adminport admin_server_port] -passwdaddr password_server_address [-passwdport password_server_port] -realm Kerberos_realm
where
-configname configuration_name specifies the name of the configuration that is to be created.
[-adaddr Active_Directory_address] specifies the IP address of the Active Directory server. This needs to be specified only if the KDC vendor is specified as Microsoft.
[-clockskew clock_skew] specifies, in seconds, the permissible clock skew. The default is 300 seconds. This value is global across all realms in the SpinServer cluster; do not modify it unless directed to do so by your Kerberos administrator.
-kdc KDC_address specifies the IP address of the KDC server.
[-kdcport KDC_port] specifies the port of the KDC server. The default is 88; this value is used unless another value is explicitly specified.
-kdcvendor {Microsoft | Other} specifies whether the KDC vendor is Microsoft or Other. If Microsoft is specified, the -adaddr parameter must be specified; if Other is specified, the -adminaddr and -adminport parameters must be specified.
[-adminaddr admin_server_address] specifies the IP address of the administrative server. This parameter needs to be specified only if the the KDC vendor is specified as Other.
[-adminport admin_server_port] specifies the port number of the administrative server. The default is 749; this value is used unless another value is explicitly specified. This parameter needs to be specified only if the KDC vendor is specified as Other.
-passwdaddr password_server_address specifies the IP address of the kpasswd password server.
[-passwdport password_server_port] specifies the port number of the kpasswd password server. The default is 464; this value is used unless another value is explicitly specified.
-realm Kerberos_realm specifies the name of the Kerberos realm.
The following example creates a Kerberos realm configuration named nfs-config1. The KDC server has an address of 10.2.127.0 and uses port 88. The KDC vendor is Other. The administrative server has an address of 10.10.0.1 and uses port 749. The address of the kpasswd password server is 10.10.0.1 and uses port 464. The Kerberos realm is KERBEROS.EXAMPLE.COM.
spinserver::> spinaccess kerberos realm new -configname nfs-config1 -kdc 10.2.127.0 -kdcport 88 -kdcvendor Other -adminaddr 10.10.0.1 -adminport 749 -passwdaddr 10.10.0.1 -passwdport 464 -realm KERBEROS.EXAMPLE.COM
Use the spinaccess kerberos realm show command to display information about one or more Kerberos realm configurations. The syntax of the command follows:
spinaccess kerberos realm show [-configname configuration_name]
The following example displays information about a Kerberos realm configuration named nfs-config1:
spinserver::> spinaccess kerberos realm show -configname nfs-config1 Configuration Name nfs-config1 Active Directory IP Address Clock Skew KDC Address 10.2.127.0 KDC Port 88 KDC Vendor Other Admin Server Address 10.10.0.1 Admin Server Port 749 Password Server Address 10.10.0.1 Password Server Port 464 Kerberos Realm KERBEROS.EXAMPLE.COM
To modify a Kerberos realm configuration, use the spinaccess kerberos realm modify command. The command has the following syntax:
spinaccess kerberos realm modify -configname configuration_name [-adaddr Active_Directory_address] [-clockskew clock_skew] [-kdc KDC_address] [-kdcport KDC_port] [-kdcvendor {Microsoft | Other}] [-adminaddr admin_server_address] [-adminport admin_server_port] [-passwdaddr password_server_address] [-passwdport password_server_port] [-realm Kerberos_realm]
The following example modifies a Kerberos realm configuration named nfs-config1 so that it uses a kpasswd password server at IP address 10.5.0.1 and port number 464.
spinserver::> spinaccess kerberos realm modify -configname nfs-config1 -passwdaddr 10.5.0.1 -passwdport 464
To delete a Kerberos realm configuration, use the spinaccess kerberos realm delete command. The command has the following syntax:
spinaccess kerberos realm delete -configname configuration_name
The following example deletes a configuration named nfs-config1:
spinserver::> spinaccess kerberos realm delete -configname nfs-config1
In an NFS environment that uses Kerberos authentication, you need to set up mapping between Kerberos-authenticated identities and NIS names so that NFS recognizes the authenticated names. Mappings are processed in the order in which they appear in the mappings list. To create and manage these Kerberos-NIS mappings, use the spinaccess kerb-nis commands.
Note: If you are using the CLI, you must delimit all regular expressions with double quotation marks ("). For instance, to enter the regular expression (.+) in the CLI, type "(.+)" at the command prompt. Quotation marks are not required in the GUI.
Use the spinaccess kerb-nis new command to create a new Kerberos-NIS mapping. The syntax of the command follows:
spinaccess kerb-nis new -vsname virtual_server_name -clientpattern client_pattern -clientpatternreplace client_pattern_replacement
The following example creates a Kerberos-NIS mapping on a virtual server named vs0. The Kerberos client pattern maps any principal in the Kerberos realm ENG.EXAMPLE.COM to the NIS user that corresponds to the principal's base name with any instance names removed. For instance, the principal named sally/admin@ENG.EXAMPLE.COM is mapped to sally.
spinserver::> spinaccess kerb-nis new -vsname vs0 -clientpattern "([^@/]+)(/[^@]+)?@ENG.EXAMPLE.COM" -clientreplacepattern "\1"
Note: To enter a question mark ( ? ) in the CLI, you must first escape the character by pressing Ctrl-V. You do not need to use the Ctrl-V sequence before entering a question mark in the GUI.
Use the spinaccess kerb-nis show command to display information about one or more Kerberos-NIS mappings. The command has the following syntax:
spinaccess kerb-nis show [-position mapping_position]
The following example displays information about the Kerberos-NIS mapping at position 4:
spinserver::> spinaccess kerb-nis show -position 4
Use the spinaccess kerb-nis modify command to modify a Kerberos-NIS mapping. The syntax of the command follows:
spinaccess kerb-nis modify -position mapping_position -clientpattern client_pattern -clientpatternreplace client_pattern_replacement
The following example modifies the Kerberos-NIS mapping at position 3. The Kerberos client pattern maps any principal in the Kerberos realm FINANCE.EXAMPLE.COM to the NIS user that corresponds to the principal's base name with any instance names removed.
spinserver::> spinaccess kerb-nis modify -position 3 -clientpattern "([^@/]+)(/[^@]+)?@FINANCE.EXAMPLE.COM" -clientreplacepattern "\1"
You can use the following commands to change the position of a Kerberos-NIS mapping:
The spinaccess kerb-nis movefirst command moves a mapping to the top of the mappings list.
The spinaccess kerb-nis movelast command moves a mapping to the bottom of the mappings list.
The spinaccess kerb-nis decreaseposition command decreases the position of a mapping; that is, moves it closer to the top of the mappings list.
The spinaccess kerb-nis increaseposition command increases the position of a mapping; that is, moves it closer to the bottom of the mappings list.
All of these commands require the -position mapping_position parameter to specify the current position of the mapping that is to be moved.
Use the spinaccess kerb-nis delete command to delete a Kerberos-NIS mapping. The syntax of the command follows:
spinaccess kerb-nis delete -position mapping_position
The following example deletes the Kerberos-NIS mapping at position 5.
spinserver::> spinaccess kerb-nis delete -position 5
In an NFS environment, you cannot enable Kerberos on a virtual interface until it has been bound to a Kerberos-enabled virtual server. To enable an interface for Kerberos, use the spinaccess kerberos ifconfig enablekerberos command. The command has the following syntax:
spinaccess kerberos ifconfig enablekerberos -ssid spinserver -ifname interface_name -spn service_principal_name [-uname admin_user_name -passwd admin_password]
where
-ssid spinserver specifies the SpinServer that is associated with the interface that is to be enabled for Kerberos.
-ifname interface_name specifies the interface that is to be enabled for Kerberos.
-spn service_principal_name specifies the service principal name (SPN). This value must be in the form nfs/host_name@REALM, where host_name is the fully qualified domain name of the virtual interface that is being enabled to use Kerberos (for example, machine.data.example.com) and REALM is the name of the Kerberos realm (for instance, EXAMPLE.COM). REALM must match the value specified by the -realm parameter of the spinaccess kerberos realm new command. See Section 16.2.3 for information about the spinaccess kerberos realm new command.
-uname admin_user_name specifies an administrative user name for the Kerberos realm. This must be a Kerberos principal that is in the same realm as the principal specified by the -spn parameter; this principal must have permission to create or modify the principal specified by the -spn parameter. You do not need to enter this parameter if it has previously been specified for the principal name specified by the -spn parameter. The value specified by this parameter is used only for the command and is then discarded; no record of the user name is kept.
-passwd admin_password specifies the password for the Kerberos administrative user given in the -uname parameter. You do not need to enter this parameter if it has previously been specified for the SPN specified by the -spn parameter. The value specified by this parameter is used only for the command and is then discarded; no record of the password is kept. The password is echoed to the console if you are using the CLI; however, the password is masked if you use the GUI.
The following example enables Kerberos for an interface named NFS1 on a SpinServer named Server1. The service principal name is nfs/harpo.data.example.com@EXAMPLE.COM. The administrative user name is smith/admin, which has a password of 0btus3.
spinserver::> spinaccess kerberos ifconfig enablekerberos -ssid Server1 -ifname NFS1 -spn nfs/harpo.data.example.com@EXAMPLE.COM -uname smith/admin -passwd 0btus3
Use the spinaccess kerberos ifconfig show command to display information about one or more Kerberos-enabled interfaces. The command has the following syntax:
spinaccess kerberos ifconfig show [-ssid spinserver -ifname interface_name]
The following example displays information about an interface named NFS1 on a SpinServer named Server1:
spinserver::> spinaccess kerberos ifconfig show -ssid Server1 -ifname NFS1 SpinServer ID Server1 Name NFS1 Port serv0 IP Address 10.5.5.1 Netmask 255.255.0.0 Failover Port VIF ID 2 Role Server Service Principal Name nfs/harpo.data.example.com@EXAMPLE.COM
Use the spinaccess kerberos ifconfig disablekerberos command to disable Kerberos for an interface. The command has the following syntax:
spinaccess kerberos ifconfig disablekerberos -ssid spinserver -ifname interface_name
The following example disables Kerberos for an interface named NFS1 on a SpinServer named Server1:
spinserver::> spinaccess kerberos ifconfig disablekerberos -ssid Server1 -ifname NFS1
Use the spinaccess exportrule commands to set up export rule sets and rules, which enable you to control access to VFSs based on clients' IP addresses and minimum authentication levels, as discussed in Section 16.1.2 . You can create rules and rule sets by using the commands detailed in the following section. To apply them to VFSs, use the filestorage vfs new, filestorage vfs modify, filestorage vfs mount, and filestorage vfs resetexportruleset commands. See Chapter 13 for information about these commands.
Use the spinaccess exportrule new command to create a new export rule set. After you create a rule set, you can add rules to it, then manage the rules. The rule-set names inherit and none are reserved; you cannot create a new rule set with either of these names. The command has the following syntax:
spinaccess exportrule new -rulesetname rule_set_name
The following example creates an export rule set named rs1.
spinserver::> spinaccess exportrule new -rulesetname rs1
Use the spinaccess exportrule show command to display information about one or more rule sets. To display information about a specific rule set, run the command with the -rulesetname parameter; to display information about all rule sets, run the command with no parameter. Information displayed includes the rule set's name and ID. The command has the following syntax:
spinaccess exportrule show [-rulesetname rule_set_name]
The following example displays information about all export rule sets.
spinserver::> spinaccess exportrule show
Ruleset Name Ruleset ID
default_ruleset 0
rs1 1
rs2 2
You can copy a rule set by using the spinaccess exportrule copy command. This command requires the name of the rule set that is to be copied and the name of the copy. The rule-set names inherit and none are reserved; these names cannot be used for a copy of a rule set. The command has the following syntax:
spinaccess exportrule copy -rulesetname rule_set_name -newrulesetname new_rule_set_name
The following example makes a copy of an export rule set named rs1. The copy of the rule set is named rs1copy.
spinserver::> spinaccess exportrule copy -rulesetname rs1 -newrulesetname rs1copy
You can rename a rule set by using the spinaccess exportrule rename command. This command requires the original name and new name of a rule set. The rule-set names inherit and none are reserved; you cannot rename a rule set with either of these names. The command has the following syntax:
spinaccess exportrule rename -rulesetname rule_set_name -newrulesetname new_rule_set_name
The following example renames an export rule set named rs1copy to the name ruleset1.
spinserver::> spinaccess exportrule rename -rulesetname rs1copy -newrulesetname ruleset1
Use the spinaccess exportrule delete command to delete a rule set and all of the rules it contains. You cannot delete the default rule set, which has an ID of 0 (zero). The command has the following syntax:
spinaccess exportrule delete -rulesetname rule_set_name
The following example deletes an export rule set named rs1.
spinserver::> spinaccess exportrule delete -rulesetname rs1
Use the spinaccess exportrule addrule command to add a rule to an export rule set that was created by using the spinaccess exportrule new command. To add a rule, you need to specify the name of the rule set, the base client IP address or netgroup to which the rule applies, the network mask that the rule matches, the strength of the read-only rule, and the strength of the write rule. The strengths of the read-only and write rules, listed in order of increasing strength, are as follows:
any—A matching client can access the VFS regardless of authentication strength.
cifs-ntlm—A matching client can access the VFS if it is authenticated by CIFS NTLM or a stronger mechanism.
cifs-kerberos—A matching client can access the VFS if it is authenticated by CIFS Kerberos or a stronger mechanism.
nfs-kerberos—A matching client can access the VFS if it is authenticated by NFS Kerberos or a stronger mechanism.
never—-Matching clients cannot access the VFS.
Note: Write access is contingent upon read-only access, so specifying a value for the -rwrule parameter that is not as strong as the value of the -rorule parameter has no effect. For example, if you give the settings -rorule nfs-kerberos -rwrule any, CIFS clients cannot access the VFS in any way, even though the value of the -rwrule parameter is any.
The command has the following syntax:
spinaccess exportrule addrule -rulesetname rule_set_name -clientmatch {client_IP_address | @netgroup_name} [-netmask network_mask] -rorule {any | cifs-ntlm | cifs-kerberos | nfs-kerberos | never} -rwrule {any | cifs-ntlm | cifs-kerberos | nfs-kerberos | never}
To specify a client IP address, enter the IP address as the value of the -clientmatch parameter and specify a netmask by using the -netmask parameter. To specify a netgroup, specify the netgroup as the value of the -clientmatch parameter in the form @netgroup_name, and do not specify the -netmask parameter.
The following example adds an export rule to the rule set named rs1. The rule applies to the client IP address 192.55.0.0, and the network mask 255.255.128.0 is used to match the rule. The rule permits read-only access to any matching clients, but requires that matching clients have nfs-kerberos authentication to write files.
spinserver::> spinaccess exportrule addrule -rulesetname rs1 -clientmatch 192.55.0.0 -netmask 255.255.128.0 -rorule any -rwrule nfs-kerberos
The following example adds an export rule to the rule set named rs2. The rule applies to the netgroup named group1. The rule permits both read-only and read-write access to matching clients that have any authentication.
spinserver::> spinaccess exportrule addrule -rulesetname rs2 -clientmatch @group1 -rorule any -rwrule any
Use the spinaccess exportrule listrules command to list the rules that are contained in a rule set. Information displayed includes the rule's rule set name, index number, client IP address, mask bits, read-only strength, and read-write strength. The command has the following syntax:
spinaccess exportrule listrules -rulesetname rule_set_name
The following example displays information about the rules in an export rule set named rs1.
spinserver::> spinaccess exportrule listrules -rulesetname rs1
Ruleset Name Index Client IP Mask Read Strength Write
Bits Strength
rs1 0 192.55.0.0 16 any nfs-kerberos
rs1 1 192.56.0.0 16 cifs-ntlm cifs-kerberos
rs1 2 192.27.0.0 16 any any
Because netgroups can have overlapping membership sets, ordering of export rules in a rule set is not automatic. You can order rules in a rule set by using the following commands:
To decrease the position of a rule (that is, move it closer to the top of the list), use the following command:
spinaccess exportrule decreaseposition -rulesetname rule_set_name -ruleindex index_number
To increase the position of a rule (that is, move it closer to the bottom of the list), use the following command:
spinaccess exportrule increaseposition -rulesetname rule_set_name -ruleindex index_number
To move a rule to the top of the list, use the following command:
spinaccess exportrule movefirst -rulesetname rule_set_name -ruleindex index_number
To move a rule to the bottom of the list, use the following command:
spinaccess exportrule movelast -rulesetname rule_set_name -ruleindex index_number
Rules must be ordered according to the following guidelines:
You cannot reorder IP address-based rules such that a less-specific rule precedes a more-specific rule.
If you have an IP address-based rule with netmask 0.0.0.0 (that is, it matches all clients), it cannot be moved from the last position in the rule set, nor can any other rule, either IP address-based or netgroup-based, be placed after it.
If you attempt to move a rule and the move cannot be performed, the SpinServer issues the error message Unable to move rule at position N. If you use the spinaccess exportule movelast command to move a rule to the last position and there is an IP address-based 0.0.0.0 rule present, the rule is moved to the next-to-last position unless it is already in the next-to-last position, in which case the preceding error message is issued.
For example, assume you have rules for netgroups @group1, @group2, and @group3, and a rule for IP address 0.0.0.0 with netmask 0.0.0.0, in that order. If you use the spinaccess exportule movelast command to move the @group1 entry, the SpinServer moves it to the position after @group3 and before the 0.0.0.0/0.0.0.0 rule. If you then try to move the @group3 rule by using the spinaccess exportrule movelast or spinaccess exportrule increaseposition command, the attempt fails because the rule cannot be moved any higher in the list.
Similarly, assume you have rules for IP addresses and netmasks 10.4.4.120/255.255.255.255, 10.3.0.0/255.255.0.0, 10.5.0.0/255.255.0.0, and 10.1.0.0/255.255.0.0. If you attempt to move the 10.1.0.0/255.255.0.0 rule by using the spinaccess exportrule movefirst command, the rule is moved to the second position in the list because the rule cannot precede the 10.4.4.120/255.255.255.255 rule.
In summary, the spinaccess exportrule movefirst and spinaccess exportrule movelast commands move the specified rule as close to the top or bottom of the list as possible, within the framework of the ordering rules. If the specified rule cannot be moved at all, the SpinServer issues an error; otherwise, the SpinServer moves the rule to the appropriate place in the list.
Note: If you are working with netgroups and export rule sets, it is recommended that you upgrade all SpinServers in a cluster to SpinFS 2.5. If there are mixed SpinFS versions in a cluster, the SpinServers running earlier versions of SpinFS do not support native netgroups and ignore netgroup-based rules. Additionally, rules and rule sets cannot be uniformly managed on SpinServers that are running earlier versions of SpinFS.
Use the spinaccess exportrule deleterule command to delete a rule from a rule set. To specify a rule, use the index number for the rule displayed by the spinaccess exportrule listrules command.
The command has the following syntax:
spinaccess exportrule deleterule -rulesetname rule_set_name -ruleindex rule_index
The following example deletes a rule with index number 2 from the export rule set named rs1.
spinserver::> spinaccess exportrule deleterule -rulesetname rs1 -ruleindex 2
To use SpinAuth, perform the following steps:
Create an NFS-Kerberos configuration on the SpinServer system. A brief overview of the procedure follows.
Create a Kerberos realm by using the spinaccess kerberos realms new command. See Section 16.2.3 for information.
Set up a NIS domain by using the spinaccess nfs domains new command. See Section 15.2.1.1 for details.
Associate the Kerberos realm and the NIS domain with a virtual server by using the spinaccess nfs servers new command. See Section 15.2.2.1 for information.
Set up Kerberos-NIS mappings by using the spinaccess kerb-nis new command. See Section 16.2.4 for details.
Enable Kerberos on one or more virtual interfaces by using the spinaccess kerberos ifconfig enablekerberos command. See Section 16.2.5 for information.
Enable SpinAuth on the virtual server by specifying the -spinauth true parameter on the vservers servers new command (for a new virtual server) or vservers servers modify command (for an existing virtual server).
On the client, use the client platform's kinit command to log on to the Kerberos realm.
On the client, run the spinauthcli command. This step assumes that the spinauthcli program has been compiled for your system. Network Appliance can supply you with precompiled spinauthcli binaries for your client platform upon request; contact your Network Appliance representative for more information. The spinauthcli command has the following syntax:
spinauthcli [-h] [-i] [-d] [-q] spinserver_name
where
[-h] displays help information for the command
[-i] queries the credential's lifetime
[-d] destroys the credential
[-q] specifies that the command runs in quiet mode
spinserver_name specifies the name of the SpinServer on which SpinAuth credentials are to be established
For example, to set up SpinAuth credentials for a client on a SpinServer named Server1.data.example.com, run the following command:
% spinauthcli Server1.data.example.com
Copyright © 2004 Network Appliance, Inc.; copyright © 2003, 2004 Spinnaker Networks, LLC. All rights reserved. Specifications subject to change without notice.